A remote procedure call (“RPC”) protocol is a common programming method for implementing the client/server model of distributed computing, in which software operates to fulfill user needs by splitting functions between “client” tasks and “server” tasks performed by various computer resources that are organized into a “network” for communication with each other, such as a local area network (“LAN”) or a wide area network (“WAN”) or the Internet. Using this model, a “client” program sends message requests to a “server” program in order to obtain information or action according to some “protocol” (i.e., a set of standard rules that determine how data is transmitted across a network) and the server responds by carrying out the request or deferring it to another time or by indicating that it cannot be fulfilled. This model allows clients and servers to be located (and to operate) independently of each other in a computer network, often using different hardware and operating systems appropriate to the function of each. It should be noted that the terms “client” and “server” only apply to a particular transaction; a particular hardware entity (host) or software entity (process or program) could operate in both roles at different times. For example, a program that supplies a remote execution service could also be a client of a network file service.
The RPC model allows a network service to be defined by a collection of one or more remote programs implementing one or more remote procedures. The procedures, their parameters, and results are documented in the specific program's protocol specification, and a server may support more than one version of a remote program in order to be compatible with changing protocols. RPC protocols implement the client/server model by allowing a client program running on one “host” computer to cause code to be executed by a “remote” server program residing on another host computer, without requiring the programmer to explicitly write program code to accomplish this. The Open Network Computing (“ONC”) RPC protocol is based on a model where the client invokes a server procedure residing in some well-specified network location by transferring control to (and eventually regaining control from) the procedure. The RPC protocol can be implemented using any of several different “network transport protocols” (such as User Datagram Protocol (“UDP”) or Transmission Control Protocol over Internet Protocol (“TCP/IP”)) that determine how to control the resources of the network to provide virtual error-free point-to-point connections between hosts for transmission of messages over the network.
A remote procedure call is initiated by the caller (client) sending a “request (or call) message” over the network to a remote system (the server), seeking execution of a certain server program procedure using “arguments” (or parameters) supplied by the client, which can contain the data to be processed as well as information on the action(s) to be taken in providing the result. A “result (or reply) message” is then returned to the client indicating the results of the action(s) taken upon execution of the remote procedure call by the server. In one model, only one of the two processes is active at any given time, i.e., the client process sends the call message to the server process and waits for a reply message from the server containing the procedure results. Once the reply message is received by the client, the results of the procedure are extracted from the message and the client then continues execution of its own process(es). On the server side, a process is dormant awaiting the arrival of a call message from a client, at which point the server process extracts the procedure parameters from the message in order to compute the results and send a reply message containing the results to the calling client, whereupon the server then awaits the next call message from that (or another) client. Under this model, one thread of control winds through the calling client process and the responding server process in a synchronous manner. However, other implementations may be chosen in which RPC calls are asynchronously executed in order to allow the client to do useful work while waiting for the reply from the server. Another possibility is for the server to create a separate task for processing each incoming call so that it can be free to receive other requests during that time.
Each call and/or reply message using the RPC protocol must provide a unique specification of a procedure to be called, as well as provisions for matching response messages to request messages, and provisions for identifying (or “authenticating”) client caller to responding service (and vice-versa) that may also include security and access-control mechanisms. An RPC service is identified by its “program number” and “version number”, along with a “network address” specifying the location(s) of the host computer(s) where the server resides within the network and may be reached by a client program having access to this information. In the case of a service available using TCP/IP protocol, the network address will be an “internet protocol” (IP) address specifying the internet location(s) of the host(s) implementing that server, combined with a TCP “port number” specifying the host input/output (I/O) connection(s) used to communicate with the server at that IP address.
Applications rely on “mapping programs” to identify the locations (specified by “addresses”) of various resources existing within a computer network. In remote procedure call (RPC) applications, clients use mapping programs (such as PORTMAP and RPCBIND) to determine the address locations of servers capable of executing various RPC functions within the network. A server identifies itself by “registering” its network address with RPCB1ND to indicate that it is available to remotely execute a procedure when called by a client located in the network. The client application then queries RPCBIND to determine the network address of the server that it seeks to use for execution of the desired procedure. The RPCBIND protocol is used to associate (or “map”) RPC program and version numbers to “universal network addresses” in order to make dynamic client invocation of remote server programs possible. Each RPCBIND program is located at a well-known network address, and associated RPC server programs register their dynamically allocated network addresses with it. The RPCBIND program then makes those addresses publicly available to clients seeking use of the registered servers. The RPCBIND program can be used for connecting RPC clients and servers over any network transport protocol.
A common use of an RPC client/server application is in allocating network memory resources using Network File System (“NFS”) servers that perform “read”, “write” and “control” procedures allowing local clients to use remote storage systems within the computer network. For example, a network file service may be composed of two program procedures, permitting one procedure to perform high-level applications such as file system access control, while the other executes low-level file input and output functions such as “reading” and “writing” the data contained in the files. A client of the network file service would request (or “call”) the RPC server to execute these procedures for use by the client. As an example, when a “NET USE” or “MAP NETWORK DRIVE” command is initiated from a local computer workstation running the Microsoft Windows® operating system, the workstation invokes an RPC client application that queries an RPC server to execute a process assigning use of a remotely located memory storage disk to the workstation. Other common examples of RPC applications include Customer Information Control System (“CICS”) payroll, accounting, or other business applications.
A problem with current RPC protocols arises from the dynamic nature of a computer network, in which distributed shared resources are “virtually” allocated on a temporary changing as-needed basis to permit the system to maintain control over access to them. If a server registers with RPCBIND by providing the IP address and port it is using at a certain point in time, the network may then change dynamically in a way that prevents a client from reaching the server if it queries RPCBIND for this resource location at another point in time, since the server IP address and/or port may have changed in the interim. The client may also obtain an address that the server is no longer using to process remote procedure calls. RFC Internet Standards 1831, 1832, and 1833 (the contents of which are all incorporated by reference as if fully set forth herein) explain how applications can use RPC protocols in distributed client/server networks, but these standards do not address use of such protocols in dynamic virtual networks.